SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of non-functional software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Process (SNAP) Assessment Practices Manual” (APM) now in version 2.4. Reference “IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements,” published October 19, 2019 (
target="_blank" rel="nofollow"
published October 2021. More information about SNAP can be found by going to YouTube and searching for "IFPUG SNAP;" which will provide a series of videos overviewing the SNAP methodology.
For more detail on the function point metric, and other organizations’ functional software sizing metrics, see the bibliography, the Wikipedia article “function point,” and numerous references in the literature.
A software user requirement also may specify "how" the software will do it, specifically "A software requirement that describes not what the software will do but how the software will do it." (ISO/IEC/IEEE 24765:2010 definition) These types of software are defined by IFPUG as being “non-functional.” The corresponding software size is measured by SNAP. The IFPUG APMIFPUG, “Software Non-functional Assessment Process Assessment Practices Manual” v. 2.4, Princeton Junction, NJ, 08550 USA 2017. details how to size the application's non-functional software. The non-functional aspects are defined and classified in ISO/IEC 25010:2011, “Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models”.ISO/IEC 25010:2011, Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
The functional size of the software, together with the non-functional size of the software, should be used for measuring the total software size of software projects. The two sizes should be used to measure the performance of the software project, setting benchmarks, and estimating the cost and duration of software projects.
Each aspect of software (the functional and the non-functional) requires work effort to develop, which is proportional to their sizes. Software development organizations can use their correlations between function points and their work effort, and between SNAP points and their work effort, to help forecast their software development costs and schedules and to audit projects to determine how well funding was spent and schedules were managed
SNAP recognizes four categories and 14 subcategories of non-functional user requirements. These are in the below table from the APM.
1.1.Data Entry Validations 1.2.Logical and Mathematical Operations 1.3.Data Formatting 1.4.Internal Data Movements 1.5.Delivering Added Value to Users by Data Configuration
2.1.User Interfaces 2.2.Help Methods 2.3.Multiple Input Methods 2.4.Multiple Output Formats
3.1.Multiple Platform 3.2.Database Technology 3.3.Batch Processes
4.1.Component Based Software 4.2.Multiple Input / Output interfaces
For example, software development to change the field sizes for data in a data table does not represent changes in functionality according to the IFPUG methods. However, this development requires work effort. Data Formatting is considered non-functional, and is countable under SNAP subcategory 1.3.
Help Methods (subcategory 2.2) are usually considered non-functional. When compared to the function point process, which requires data to cross an application's boundary and maintain an internal logical file, the Help data may be coded to reside internally as part of the application development and be accessed upon command from the user. This access can be anything from bubble help over an icon on a screen, to access of part of an internally stored application operations manual. Data is not being processed per se, so Help is usually considered non-functional.
Function points and SNAP points measure two different aspects of software sizing, and therefore are not added together. For example, an application of 500 function points and 300 SNAP points cannot be considered to be the size 800 of some metric; function points and SNAP points are intended to be orthogonal. A good reference for further detailed information regarding the relationship between functionality and non-functionality is in the document “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating”.COSMIC, IFPUG, “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating,” v. 1.0, September 2015.
Further, some software development efforts might be measured as having zero function points. For example, an Agile software maintenance sprint might be required only to change the length of data fields in data tables. This would be measured to have zero function points because it is non-functional; however, that work would be accountable in SNAP. SNAP at least partly solves the “0 function point” problem.
International Function Point Users Group, “How Function Points and SNAP Work Together,” MetricViews, www.ifpug.org, Princeton Junction, NJ, 08550, USA, August 2015.
Jones, Capers, “A Guide to Selecting Software Measures and Metrics,” CRC Press, Boca Rotan, FL, 33487, USA, 2017.
Jones, Capers, “Quantifying Software Global and Industry Perspectives,” CRC Press, Boca Rotan, FL, 33487, USA 2018.
|
|